Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.travis.yml: enable caching for dep #1063

Closed

Conversation

AlexNPavel
Copy link
Contributor

Description of the change: Enables caching for dep. This should improve CI times, but can cause problems if dep's cache gets corrupted. See this PR for more info: golang/dep#1293 (comment). We may manually have to reset the cache in the case of corruption.

Motivation for the change: Speed up CI. Closes #1062

Enables caching for dep. This should improve CI times, but can
cause problems if dep's cache gets corrupted. See this PR for more
info: golang/dep#1293 (comment)
@AlexNPavel AlexNPavel added the area/testing Issue related to testing the operator-sdk and subcomponents label Feb 5, 2019
@openshift-ci-robot openshift-ci-robot added the size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. label Feb 5, 2019
@fabianvf
Copy link
Member

fabianvf commented Feb 5, 2019

It may also be useful to have a pre-stage that builds and caches the operator-sdk binary, so that the Ansible and Helm stages can skip dep ensure + build entirely

@AlexNPavel
Copy link
Contributor Author

It may also be useful to have a pre-stage that builds and caches the operator-sdk binary, so that the Ansible and Helm stages can skip dep ensure + build entirely

That would be nice, but it's unfeasible due to the way that travis caching works. Travis just bundles up the entire directory as an archive that gets downloaded and extracted to the machine, and if something changes, that directory gets rearchived and uploaded. To prevent cache conflicts between builds, we would need to have separate binary for each build (maybe by appending the git SHA), which would result in an archive that could easily reach GBs in size within a week. Sadly, travis doesn't seem to provide any build-local caches. In this case, caching dep is a bit more reasonable (though the dep cache for the SDK is still very large at 2.3GB for current master).

To speed up build time, we could cache ~/.cache/go-build (which would allow for near instant compile during the build phases), but again we have the issue of a very large cache (164MB for current master and Go 1.10.3).

@AlexNPavel
Copy link
Contributor Author

/hold
It might not be reasonable to store the 2.3GB dep cache in travis's cache. If we store our vendor in git (currently ~59M), that would result in dep taking only a couple of seconds and avoid having a monstrous cache. We should discuss this more before merging this PR.

@AlexNPavel
Copy link
Contributor Author

/hold

@AlexNPavel AlexNPavel mentioned this pull request Feb 5, 2019
@AlexNPavel AlexNPavel closed this Feb 6, 2019
@AlexNPavel AlexNPavel deleted the travis-cache branch February 6, 2019 18:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/testing Issue related to testing the operator-sdk and subcomponents size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants